home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1994 June: Reference Library / Dev.CD Jun 94.toast / Periodicals / develop / develop Issue 10 / develop 10 code / Is it Art? / ArtMaker / ArtMaker Notes < prev    next >
Encoding:
Text File  |  1992-04-13  |  5.6 KB  |  32 lines  |  [TEXT/ttxt]

  1. •Using ArtMaker
  2. It's pretty simple, really. Just open any PICT file, choose a brush from the "Brush" menu, and start painting. When you open a file, you'll get 2 windows: the "source" (the PICT you opened) and the "destination" (where the painting happens). The source window's name is the same as the name of the PICT file you opened, and the destination window's name is the name of the file with "Art?" appended to it. Each window is individually saveable, printable, etc, but a "document" in this app means both windows, so for instance if you close the source the destination goes away too. You can paint with the mouse in either of the windows, but all brush strokes go to the destination, where they belong. You can also paint "automatically" (See the Auto-Paint menu). That's the basics. Play around with the available brushes to see what they do, and you'll quickly get the idea
  3.  
  4. While writing this app I put lots of effort into doing things the "right" way, at least most of the time. So for instance the window zooming behavior tries to emulate the Finder: if I can leave the top left corner of the window where it is and still zoom I will, if the window crosses screens it will zoom to the one it is mostly on, and so on. Unfortunately, doing things the right way is often difficult and time consuming, so a few things fell through the cracks (deadlines, ya know). Notably, ArtMaker will not open files from the Finder, you have to launch the program and then select Open from the file menu. I could have fairly quickly done it the old crusty way, but decided that it should be done right (Apple Events) or not at all. Unfortunately, I ended up putting my compiler where my mouth is (or something), and it didn't get done. So it goes. (Hey, at least it's got Undo and Print, and besides, if you don't like it you can fix it since you've got the source).
  5.  
  6. Please, if you find bugs or problems, let me know.
  7.  
  8. AppleLink:        JOHNSON.DK
  9. CIS:                            75300,715
  10. Internet:            dkj@apple.com
  11.  
  12.  
  13. •About the code
  14. A lot of the stuff I did in this app I did for the first time, so I'm sure my solutions aren't always the best ones. But damn, I learned a lot. I tried to comment the code thoroughly so that the things that you can learn from my trials and errors. Following is a discussion of some of the high points.
  15.  
  16. The Shell: The basic Mac code (event loop, etc.) is in a Shell that I've had lying around forever, and have refined over the years. It is not a complete app shell, but it's pretty good and I'm familiar with it. You shouldn't have to even look at it unless you want to. Take a look at the file AppInterface.h for a list of the routines that the shell calls and that the app needs to respond to. Quite frankly, I think probably MacApp or the THINK class library is the way to go these days...
  17.  
  18. Window Zooming: I took Craig Prouse's famous DoWZoom routine as a starting point, but added some new stuff to it. Basically I tried to emulate the Finder: if I can leave the top left corner of the window where it is and still zoom out I will; if the window crosses screens it will zoom to the one it is mostly on; windows only zoom to their maximum useful size; etc. The big gnarly routine that resulted is called ReadyWZoom and is in PainterlyUtils.c. Check it out.
  19.  
  20. Scroll bars: What a pain in the ass! See the code for more details, in particular the AddStdScrollBars routine in PaintInit.c and the AdjustScrollbars routine in PainterlyUtils.c.
  21.  
  22. Title bar Height: There's a nasty problem when you want to do intelligent window placement. The only way to get the title bar height of a window in an internationally cool way is to calculate it from the window's structure region, but the structure region is invalid unless the window is visible. In my case, I wanted to size and position a window while invisible and then show it, but I couldn't get the title bar height with the window invisible. The solution? At startup, I call a routine that creates a tiny visible window that is off all screens, so the user can't see it, and calculate its title bar height, saving it in a global. Later, I use the global value when I need it. It's a sick kludge but so is a large chunk of the Macintosh Toolbox (the Resource Manager springs to mind...). Anybody out there know a better way to do this?
  23.  
  24. Opening Windows: Windows in ArtMaker are always opened on the deepest device, rather than the main device (see the SetUpAndShowWindows routine in Painterly.c), but there is a small problem. If you have 2 monitors set to the same depth, windows should logically show up on the main screen, but they don't always, since I used GetMaxDevice() to determine which monitor to use, and it doesn't always return the main device if there is more than one with the same depth. The fix would be to call both GetMaxDevice() and GetMainDevice() and look at their depths. If they are the same, use the main device. I ran out of time before I could fix this tiny snafu.
  25.  
  26. PICT spooling: I used PICT spooling for both opening and saving files, but only if there isn't enough memory to do it all in RAM. The spooling is "by the book," and is consequently verrrrry sloooow. 
  27.  
  28. File handling: I used the System 7.0 FSSpec routines, 'cuz I like 'em. That's one of the major reasons that ArtMaker requires System 7.0.
  29.  
  30. Writing Brushes and Filters: The best way to figure it out is to look at some of the examples. It's pretty simple, really. I admit I went a little wild on some of the configuration dialogs, and hereby plead guilty to Dialog Manager Abuse as defined in Bo3b Johnson's Tech Note (I forget the number, but it's called "Don't Abuse the Managers." If you haven't read it, you are slime and should be forced to rewrite the resource manager in COBOL). But it was a lot of fun, dammit.
  31.  
  32.